IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The integration of an IP Multimedia Subsystem into a 3G mobile communications system is illustrated schematically in FIG. 1.
IMS relies on Internet Protocol (IP) as a transport technology. Using IP for voice communications, however, presents some challenges, especially in the mobile community where Voice Over IP (VoIP) enabled packet switched (PS) bearers may not always be available. To allow operators to start offering IMS-based services while voice enabled PS-bearers are being built out, the industry has developed solutions that use existing Circuit Switched (CS) networks to access IMS services. These solutions are referred to as IMS Centralized Services (ICS). ICS is also the name of the Work Item in 3GPP Release 8 addressing these matters.
Supplementary Services in GSM/UMTS
Global System for Mobile Communications (GSM)/Universal Mobile Telecommunications System (UMTS) allows subscribers to apply supplementary services to basic services. An example of a supplementary service (SS) is the Call Forwarding SS. The Call Forwarding SS is a service for forwarding all incoming calls, for example to a voice mail system. In this example, Call Forwarding is the supplementary service and telephony is an example of a basic service. Basic Services are grouped into tele-services and bearer services, and telephony is one of the GSM defined tele-services. The basic services available in GSM/UMTS are illustrated in FIG. 2.
SS-operations are used to manipulate supplementary services. For example, an SS-Operation is used set a forwarded-to-number with a voice mail system. These procedures are also referred to as Call Independent SS procedures and they take place between a user terminal (which may be a mobile station, User Equipment, or other means of accessing the CS access network) and the subscriber's Home Location register (HLR). After a successful SS-Operation, the data relating to the supplementary service is updated in the HLR. Note that in this documents, the term HLR is used to refer to either an HLR or HLR functionality in another node such as a Home Subscriber Server (HSS).
Some supplementary services are handled by a Mobile-services Switching Centre (MSC) or Visitor Location register (VLR). An example of such a service is Call Forwarding On Busy. For these services, the HLR updates the MSC/VLR with the new data with an Insert Subscriber Data procedure.
The available SS-Operations are:                Register SS        Deregister SS        Activate SS        Deactivate SS        Interrogate SS        USSD operations:        Process Unstructured SS Request        Unstructured SS Request        Unstructured SS Notify        
Registration for a supplementary service in a GSM/UMTS network is shown in FIG. 3.
Different SS-Operations are used for different supplementary services, that is to say that not all supplementary services use all of the SS-operations. Applicable SS-Operations are defined for each type of supplementary service. For all supplementary services, it is possible to check the status of the supplementary service, that is to say whether or not a supplementary service is currently active, and what data has been set for the supplementary service. This is performed using the Interrogate SS-Operation.
Generic signalling principles for supplementary services are described in 3GPP TS 24.010. Signalling for individual supplementary services is described in the specifications 3GPP TS 24.072-24.093.
In additional to the call independent SS-procedures, there are call dependent SS-procedures which are executed by the MSC/VLR. Examples of these are call hold, call waiting and explicit call transfer. Call dependent SS-procedures are directly coupled to the execution of these services, e.g. notifying a busy subscriber of a waiting call, the ability for the subscriber to toggle between two calls, and so on. Activation of the call dependent SS-procedures is carried out using the call independent SS-procedures described above.
The SS-operations are hidden behind the terminal Man Machine Interface (MMI), e.g. the displayed menus for setting data for supplementary service in a mobile phone. It is, however, possible to manipulate SS-data by dialling certain Service Codes. For example, **21*telephone number*11# means that all calls for teleservice=11 (telephony) are to be forwarded to the indicated telephone number. 21 in the example is a service code for unconditional call forwarding.
Unstructured Supplementary Service Data (USSD) messages also contain a Service Code (SC). For user terminal-initiated USSD messages, the SC is generated by the user terminal or the subscriber, and includes digits, letters, and/or signs. Any SC that is not defined as a standardized supplementary service n the MS, is interpreted as USSD by the user terminal. SCs that are recognized are mapped to the SS-Operations as for the call forwarding example above.
IMS “Supplementary Services”
IMS multimedia telephony offers a number of standardized “supplementary services” (or service settings), many of which are similar to the GSM/UMTS supplementary services. The IMS supplementary services have extended capabilities for setting data that govern their execution, for example to define criteria for the execution of the “session forwarding” that is dependent on the caller, what media the session is intended for, etc.
IMS has a communication service concept that allows supplementary services to be defined and set specifically for each communication service. The IMS communication service most similar to the telephony tele-service is the Multimedia Telephony communication service (MMTel). Supplementary Services for Telephony (tele-service) and MMtel (IMS communication service) are shown in FIG. 4.
IMS uses eXtensible Markup Language Configuration Application Protocol (XCAP) signalling for manipulation of supplementary service data. As GMS/UMTS networks do not support XCAP, the SS-operations in GSM/UMTS cannot be used to set data for supplementary services in IMS.
Even though there are many similarities between the supplementary services for GSM/UMTS telephony and IMS MMTel, the procedures for operating on the SS-data are totally different. This becomes inconvenient when a subscriber using a CS access network wishes to use IMS services. IMS Centralized Service (ICS) enables services to be provided to users independent of the access that they are currently using. A subscriber may at a certain time only have a CS access available, and can then not perform any manipulations of supplementary services with XCAP, since XCAP signalling requires PS access. Furthermore, there is no support for “legacy terminals” that are not IMS capable but are equipped only with GSM/UMTS SS-Operations and cannot use the XCAP procedures defined for IMS.
Another problem arises when some services are provided by an IMS network, and also via the CS domain, depending on what domain the terminal is using at that time. If the services are not centralized as described above, then there is the risk that the user can be confused, as there are two independent sets of data. In such a case, a user, when accessing the network via the CS domain, may change their call forwarding settings. That user would be confused when, at a later time, the call forwarding settings do not apply if a call is received over the IMS.
Previous solutions to these problems have included:                Having XCAP signalling from an Access Gateway Control Function (AGCF). A MSC server could take on such a role. In such a solution, the MSC server would interpret SS procedures and initiate IMS XCAP messages.        The HLR could implement XCAP. In such a solution, the HLR processes the SS procedures from the circuit switched domain and initiates XCAP procedures towards the IMS. However, such a system requires that the HLR has knowledge of the IMS network that it will forward messages to, and must translate between protocols.        